Description

Bumps yamux to resolve a high severity vulnerability by eliminating the
vulnerable yamux 0.12.x dependency from the build.

Type of Change

• Bug fix (non-breaking change which fixes an issue)

Security Alert

• Alert: https://github.com/okx/xlayer-reth/security/dependabot/13
• CVE / ID: CVE-2026-32314
• Severity: high
• Vulnerable range: < 0.13.10
• Fixed in: 0.13.10

Change

libp2p-yamux 0.47.0 (the latest release) intentionally depends on two
versions of yamux simultaneously:

• yamux 0.12.x (aliased yamux012) — legacy backward-compat path, vulnerable
• yamux 0.13.x (aliased yamux013) — new default path, safe

The xlayer codebase uses only yamux::Config::default(), which already routes
through the yamux013 code path at runtime. However, yamux 0.12.x was still
compiled into the binary, keeping the vulnerable parsing code present.

Because no upstream release of libp2p-yamux removes the yamux012 dependency
(libp2p 0.56.0 is the latest), this PR introduces a local fork of libp2p-yamux
under deps/libp2p-yamux — following the same pattern used for the previous
jsonwebtoken security fix (deps/alloy-rpc-types-engine).

The fork:

1. Removes the yamux012 dependency from Cargo.toml
2. Rewrites src/lib.rs to use yamux 0.13.x directly (no Either<v012, v013>)
3. Removes the deprecated Config::client(), Config::server(),
   set_receive_window_size(), set_max_buffer_size(), and
   set_window_update_mode() methods (none are used in this codebase)
4. Keeps the set_max_num_streams() method, updated to use the yamux013 API

A [patch.crates-io] entry in the workspace Cargo.toml redirects
libp2p-yamux to the local fork. After the patch, cargo check --workspace
passes cleanly and Cargo.lock contains only yamux 0.13.10.

Checklist

• I have reviewed the relevant code guidelines in the docs/ folder
• My code follows the coding standards of this project
• I have performed a self-review of my own code